1. Field of Art
The present invention generally relates to project management, and more specifically, to facilitating project management by providing a user with visual display of project parameters.
2. Description of the Related Art
Companies are challenged with leveraging different process methodologies for their project planning, development, and implementation efforts. Example processes include project management, quality assurance, change management, team communications, Sarbanes Oxley, etc. These processes are silos, meaning that their focus is for one process area and they do not take into account other process areas. (The terms “process”, “best practice”, and “process methodology” are used interchangeably and all represent the same concept). The problem is the difficulty to manage these different processes in an integrated fashion, as enterprise solutions require more business and technology integration (sharing, manipulating, and storing the same data). Project managers are now faced with controlling these different and complex process needs manually and many do not have the needed knowledge or experience.
Some organizations that have pre-defined best practices for managing projects or for managing regulations and compliance needs use simple technologies such as stored text documents placed on file servers. The organization's project teams may know where to find the documents, but many people do not spend enough time learning and reviewing the processes to ensure compliance, especially since the documents are not designed for day-by-day processing. Also, they do not have a way to easily link those stored documents directly with project template files and project deliverable files used for implementing projects.
Current advances in computer software programs are making inroads to providing technology solutions that better manage project best practices. Most of these technologies are driven by functions rather than process. Their user interfaces are designed with functional tasks that are grouped in a hierarchal folder or directory structure. The user behavior is restricted to selecting and drilling down to deeper levels before being able to locate their process step. In addition, this user interface does not make it easy to associate project stages (i.e., plan, build, test) as shared categories without requiring the user to either create the same set of project stages for each directory containing best practices. Another difficulty comes when the user wants to compare one set of best practice steps with another set of best practice steps while reviewing the same project stage. The hierarchal structure fails when each process step is to display information on process details, people roles and responsibilities, and project deliverable files.
An example of an existing hierarchal structure in the marketplace is as follows. If the best practice was called “project management”, a directory would be called “Project Management”. Within this directory, there would be subdirectories called “Plan”, “Design”, “Build”, “Test”, and “Deploy”. In each of these subdirectories there would be more subdirectories called “Process Details”, “People”, and “Deliverables Files”. Now if there were a second best practice for “quality assurance”, it too would contain all of the subdirectories with more subdirectories. The user experience would be complex, especially if the user wants to relate one step within “Project Management” with a step within “Quality Assurance”. The depth of these directories restricts user adoption and productivity. This is why many technologies focus on one best practice set or restrict their programs to be more of a task management system that does better with a list of task items than a platform for containing best practice processes.
Another type of technology is process engine software used mainly for defining business process steps. These are sophisticated programs that allow users to design a process from scratch and then define software program business rules to execute when the process events are implemented. The common outcome of these tools is meant for driving custom process steps that are not related to repeatable projects. The user interfaces for these process engine tools are combinations of hierarchal and graphical views. The hierarchy contains directories for process areas, which contain subdirectories and more subdirectories. Once a process area within a directory is located, the viewer then sees the process in a visual graph representation. One problem with this user interface is similar to the task technology above where the hierarchal views make is difficult to relate different process sets with each other. Another problem with this user interface model is the graph objects do not easily relate to other factors like detail process information, people roles and responsibilities, and file deliverables. The reason is that most of these types of user interfaces are more for executing program business rules than for displaying associated data. Furthermore, these user interfaces fail to present high level, mid-level, and detailed level information on the same page. Users get lost in complicated user interfaces that require a lot of hunting to find what they need and contemplating to figure out where they are.
Organizations need to learn how-to-use information from their third-party vendor tools that they have invested in for their projects. For example, many organizations use multiple technologies to implement projects, such as software for project planning, requirements definition, special calculations, and resource management. Currently, the how-to-use data is usually contained in that tool's help file, user manual, or other form of documents. These how-to-use manuals are functional based and are not related to a best practice such as project management, quality assurance, or change management. That makes it difficult for the organization to learn how to best use their tools in relationship to these processes. The user interfaces for the above mentioned task management technologies and process management engines are not designed for dealing with other third-party tools. Their user interfaces are not well suited to provide any visibility to on how to use other third-party technology tools with associated best practice content. Some may have text fields to contain any extra information, but this is cumbersome since the user may not find any consistency on how data is presented from one process step to another.
It is desirable to provide a user interface that overcomes the limitations of existing technology user interfaces as mentioned above. A desirable user interface is one that provides a matrix view of process best practices with project slices (stages) on the x-axis and the best practice layers on the y-axis. This desirable user interface has a third dimensional view for process, people, and deliverable content as they relate to each of the cells in the slices (x-axis) and layers (y-axis). In addition, the top view of the slices is presented with a circular “pie” metaphor to show that projects are iterative as they evolve over time. For example, once you get to one end, you circle back and start over again at the beginning. These preferable views have a better means for presenting multiple best practices content at the same time.